Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: ensure in CI that there is no dependency to snapshots #5395

Closed
wants to merge 3 commits into from

Conversation

monperrus
Copy link
Collaborator

@monperrus monperrus commented Aug 25, 2023

fix #5340

@I-Al-Istannen
Copy link
Collaborator

Changing the spoon-pom version is done by the release workflow now. If we do not bump that to a new snapshot version, we are unable to change anything in there during development, as spoon-core will use the old, released version.
The release commit (e.g. c41c407) should use a proper non-snapshot version, but I do not see a nice way to maintain that property during development.

What is the reason for this change? Is it necessary, that spoon snapshot versions (i.e. currently being worked on) never refer to spoon in a snapshot state? I would think that only the final release version must point to fixed, stable version numbers.

@monperrus
Copy link
Collaborator Author

What is the reason for this change? I

The primary reason is that this is the cause for which many jobs our integration CI (checking that client code still works on SNAPSHOT) are broken: https://ci.inria.fr/sos/. The underlying root cause is that spoon-parent is not snapshot CDed.

To fix the integration CI, I see two options:

  • this one
  • set up snapshot CD for spoon-parent

I prefer this one because 1) it minimizes coupling, 2) this check is very meaningful and useful in general, beyond this current breakage.

@I-Al-Istannen
Copy link
Collaborator

I-Al-Istannen commented Aug 26, 2023

The problem with your solution is that changes in spoon-pom (e.g. to update dependencies) will be built in the release commit for the first time.

As an example, consider this sequence of events:

  1. Renovate changes a dependency in spoon-pom to a new, breaking release
  2. Our CI builds spoon-core, but it references the released and published older spoon-pom without the change
  3. The CI subsequently passes
  4. When we make a new spoon release, the release commit breaks and we have to untangle the dependency mess, potentially downgrading things again

To ensure changes in spoon-pom are directly applied, we would need to leave the version of the spoon-pom in this repository the same after a release. This is not a good idea though, IMHO, because then we have multiple spoon-poms with the same version tag but different contents.


Btw, https://ci.inria.fr/sos/ seems to only show builds if you are logged in — and I don't believe I have an account :)

@monperrus
Copy link
Collaborator Author

As an example, consider this sequence of events:

This would work, the CI would build what's written in the code for a given commit. And then Renovate would update spoon-parent one's newly released.

To ensure changes in spoon-pom are directly applied

Yes, we would exclude this workflow on purpose. We would change spoon-pom, release it and then update in another commit. On this topic, I've created long time overdue #5397

@monperrus
Copy link
Collaborator Author

any idea why and how github-actions[bot] reacted with thumbs up emoji?

@I-Al-Istannen
Copy link
Collaborator

This would work, the CI would build what's written in the code for a given commit. And then Renovate would update spoon-parent one's newly released.

I am not sure I follow. How would the changes in spoon-pom be picked up by spoon-core, if spoon-core refers to an old version of the parent? I think spoon-core would either use the previous versions spoon-pom (if we only update the parent after the release) or might fail in the release commit for the first time.

I am not really keen on the version of the parent and core going out of sync in a way that delays dependency errors until a release happens. Maybe I am just missing something?

any idea why and how github-actions[bot] reacted with thumbs up emoji?

Qodana found no issues (and used the github actions token to create the reaction)

@monperrus
Copy link
Collaborator Author

How would the changes in spoon-pom be picked up by spoon-core, if spoon-core refers to an old version of the parent?

It would not, and that's exactly the point. If we want to change the parent, the workflow is:

  • change parent pom
  • review and merge change in parent
  • release parent
  • change parent relationship info clients, incl. spoon-core
  • review and merge change in clients

Fully reproducible dependency. The parent always point to an addressable, immutable, reproducible dependency (think NIX :).

On a related note, #5397 is the best option for making everything explicit with the same properties.

@I-Al-Istannen
Copy link
Collaborator

I see, I didn't understand that you actually wanted that behaviour.

Fully reproducible dependency. The parent always point to an addressable, immutable, reproducible dependency (think NIX :).

It doesn't help much currently as our SNAPSHOT versions are not bumped for every commit, so you have no idea what "spoon-core-SNAPSHOT" refers to without a git hash. And if you have the git hash, you also have the used spoon-pom version and the reactor build should resolve the parent properly, I think. For spoon-core releases we already point to fixed spoon-pom versions in the parent.

On a related note, #5397 is the best option for making everything explicit with the same properties.

I agree. I think that's the easiest option…


This PR necessitates changes in our release workflows. Currently they bump the spoon-pom parent version and release spoon-pom in the same CI afaik. What you propose would require one release workflow for spoon-pom and one for spoon-core. We can make those changes after (maybe) merging the Nix PR, we just likely do not want to make an automatic release after this PR is merged.

@monperrus monperrus closed this Aug 21, 2024
@monperrus monperrus deleted the monperrus-patch-3 branch September 3, 2024 13:19
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.

Failed to read artifact descriptor for Spoon 10.4.1-SNAPSHOT
2 participants