-
Notifications
You must be signed in to change notification settings - Fork 16
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
Continuous integration #4
Comments
I'm planning to open source some code next month, for testing each push/commit through GitLab CI. |
That's great news! Looking forward for your code. BTW, I am currently using |
That's great @tortuetorche. Let me know when it's out. I think we could use the GitLab's GitHub integration feature. Or maybe just move to gitlab.com?🤔 |
💯 |
Hi @greenled, The continuous integration with GitLab CI is almost done! Can you add me as a Have a good day, |
Hi @tortuetorche. I just added you as a collaborator. Welcome onboard! Please import the project into the psuapp organization with issues, pull requests and everything else that can be imported. We are #movingToGitLab. Let's rock that CI pipelines! I have some big news to share too. I have been working on a complete rewrite of the codebase...in Go. It's a radical change but I believe it's for the good, it will lean the way in the long run. Bash is great for scripts (the smaller, the better), but when you want something more complex (long AND short flags, commands and subcommands for context like in I feel very happy with the result. I brought most features from the bash version, implemented some of the ones you added to the next branch and I'm looking forward to implement the rest. Of course, if you happen to speak Go lang I encourage you to implement them by yourself (sorry for the double work 😅, I see you have been working hard in the next branch). |
Hi @greenled, This is great news! PS: I never coded in Go Have a good day, |
I like the first approach: releasing your *next * branch as a 1.x version and releasing the Go code as a 2.x version. This way all the contributions you made and the ones to come will stay in the project. This is what I am thinking to do:
What do you think? BTW, if you have the time and interest I would highly recommend you learning Go. It's a beautiful and powerful language. I had never coded in go either, until I summed up the issues I described before. Have a good day, |
Alright, but we should follow GitLab Flow and name stable branches like I can't import this repository to GitLab with issues and pull requests, because I'm not the owner... |
Hi @greenled, Any news to import this repository in GitLab with issues and pull request? Have a good day, |
Hi @tortuetorche. I have got another idea:
What do you think? I have been thinking too about renaming the project (not only the namespace) to avoid possible trademarks issues. I opened #17 to address that. Does any name come to your mind? I think this should be done before migrating to GitLab, as group and repository name should reflect this change. Meanwhile you can still work on the CI script. Regards, |
Hi @greenled, OK, but all the links of my So I don't think it's a good idea to merge my branch before GitLab migration... Have a good day, |
OK, I just started the import into psuapp/psu. It should not take long. |
It's been importing the project for eight hours. I removed the project and reimported it, just in case. |
Please let's keep the discussion about migration to GitLab on #19, this issue's topic is CI. |
@tortuetorche I started reviewing in depth your latest changes to the Sometimes you batch several unrelated changes (feature additions, bug fixes, typo fixes, version number bumps...) into a single commit and name commits against a version number instead of a short description of what has been done, which is instead described on next lines of the commit message. This makes it hard for me to understand your work, and will make it hard too for anyone else who wants to read the project's history. Please could you rewrite your I apologize for this back, forward, back again. This is the first time I deal with large contributions and I have a lot to learn about the process, like adding a contribution guide. |
As migration to GitLab #19 is not going as expected I am considering using another of the available CI solutions like Travis CI, Circle CI, Drone.io. Whatever is chosen, it should work like GitLab CI as much as possible, so future migration can be easier. |
The script should be tested on each push in an easy, reproducible and auditable (public) way. A bonus benefit would be the ability to run tests against several Portainer versions to ensure compatibility.
The text was updated successfully, but these errors were encountered: