Skip to content

Conversation

k-yle
Copy link
Member

@k-yle k-yle commented Oct 13, 2024

Currently, anyone who wants to consume ELI's data has to fetch the data directly from the main git branch (via github pages or github), since this repository does not do versioning.

This can be risky, and cause confusion when the CI is failing on the main branch (like what happened last week).

To give data consumers more certainty, this PR introduces a weekly cronjob which moves a git tag to the latest commit on the main branch, but only if the CI is passing.

This gives people the flexibility to consume data directly from the main branch, or from this git tag if you want to be more safe.

Tested in a fork of this repository (logs here)

@andrewharvey
Copy link
Collaborator

andrewharvey commented Jan 21, 2025

cc @arch0345 @grischard @rbuffat @cicku

I had suggested an automated versioned release in #574 but was promptly shut down, but due to changes in the maintainers we should consider this again.

I think what you're suggesting is still an improvement over the status-quo and fine with me though I would make it run daily, given it's automated there's no real reason to delay it a week in my opinion.

I also think we should go further and implement automated version releases pushed to npm.

@grischard
Copy link
Collaborator

I would rather make sure we only push to the main branch when CI is passing, instead of adding the complexity of tags.

@k-yle
Copy link
Member Author

k-yle commented Jun 21, 2025

I would rather make sure we only push to the main branch when CI is passing

I'm not familiar with ELI's CI system, but just a general comment: This is an impossible problem to solve.

Even if you enable "Require branches to be up-to-date before merging", there's still a slight chance that the CI will fail on the mainline branch, like what happened during the week when I raised this PR.

Neither Git nor GitHub has a technical solution that will ensure the mainline branch is always passing, hence the need for releases1

Footnotes

  1. or an indicator of the last stable commit, as proposed here

@gy-mate
Copy link
Contributor

gy-mate commented Jun 21, 2025

I agree—versioning (i.e. tagging) seems like a more stable and verifiable solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants