bradrydzewski

We do not have native support for limiting Pipelines or Pipeline steps based on files changed, however, this can be achieved with plugins. I wrote a post about it here: https://github.com/drone/drone/issues/1021#issuecomment-4178...

There is a lot of interest in a plugin that supports limiting step execution, so I would love to work with teams that have mono-repository experience to come up with a solution. Perhaps eventually the plugin would become part of Drone core ...

See section 4.4 https://drone.io/enterprise/license/

edit: section 4.4 provides a business discontinuation clause that specifies the source code will be released under an open source license if the business is discontinued. The clause was written by an attorney (not something I added myself).

I really enjoyed following the WASM CLs. A huge effort from both neelance and the reviewers. Thanks to everyone that donated their time to make this happen!

If the compiler output is deterministic perhaps the Go runtime and Go standard libraries could be bundled as modules, allowing for aggressive cache policies. Maybe even served from a central CDN. Just a thought ...

Can you point me to the line in the license file that clearly demonstrates Redis is not open source? https://github.com/antirez/redis/blob/unstable/COPYING

fwiw gitlab also has opt-out telemetry that includes identifiable data such as instance hostname https://docs.gitlab.com/ce/user/admin_area/settings/usage_st...

Yes exactly. I am not interested in subsidizing the one-time cost of hiring an attorney to draft a compliant privacy policy and create boilerplate email templates. It is just easier to outsource the forum to a company that can (reddit).

Thanks for posting! Does Twirp use a single HTTP request per call, or does it use a persistent connection similar to the net/rpc package? If the latter, does it provide options for heartbeat, reconnect and retry?

EDIT: the blog post covers this in the protocol section. Every request is a POST :)

What would it take to enable iOS builds in an open source project like drone? It is true that drone is primarily focused on container runtimes (linux amd64/armhf/aarch64 and windows) but perhaps we could have a separate yaml and agent that executes a pipeline on the host machine, perhaps using sandbox-exec for isolation.

I think this incorrectly interprets my comment. I am not defending apple or blaming the individual that disclosed the vulnerability on Twitter. I am simply pointing out that putting users at additional risk because you want to see Apple hurt may be misguided. We have responsible disclosures in place for a reason.

EDIT: putting users at _additional_ risk

Responsible disclosure does not prevent negative publicity. It provides the vendor with a grace period during which they can fix the vulnerability. There can be plenty of negative publicity once the vulnerability is patched and publicly disclosed.

Encouraging irresponsible disclosure because one wants to see Apple hurt is a reckless and selfish attitude because it puts millions of Apple customers at risk in the process.

minor edit: 96 companies. Turn Inc is listed twice

> or that isn't intrinsically linked to a git repo

This is required because the configuration is versioned in the git repository.

> has no concept of a build triggering arbitrarily

This is not entirely correct anymore. Drone can trigger builds and deployments using the API or the command line utility, and there is a PR to add to the user interface [1]. The caveat is you need to trigger from an existing build or commit, because Drone needs a commit sha to fetch the configuration from the repository.

There are individuals using Drone + cron to execute scheduled tasks such as security scans and nightly integration tests.

[1] https://github.com/drone/drone-ui/pull/69

FWIW my understanding is the vuejs template language is based on an early version of the web component template specification (which might predate the jsx specification). You may therefore notice a good amount of overlap between vuejs templates and polymer, for example.

fwiw I read this comment and didn't find it dismissive at all. shykes indicated this isn't the experience the docker community is striving for and asks for specific instances so that he could gain more context and to potentially address the problem.

I have seen many instances of individuals with no affiliation to an open-source project being negative or rude and therefore giving a negative impression of the community or parent company. As a project owner or maintainer this is a really difficult thing to see happening, and can be difficult to address and prevent. So I personally think shykes makes a valid point. I wouldn't take this as dismissive. Give him the benefit of the doubt.

I also think we should cut maintainers a bit of slack. Imagine your are managing an open source project with over 10,000 logged issues and even more in the community forums. It is draining to spend all day dealing with complaints and issues and can be a thankless job. Maintainers often try to put their best foot forward, but it isn't an easy and they are human, and make mistakes and say things they regret. I'm not saying it is justified, just try to put yourself in their shoes.

I've personally logged a few issues with the Docker team and have also found the interactions to be respectful. There are times when I've asked for features and they have certainly played devils advocate, but that is to be expected with any project that is trying to prioritize their work and constantly fighting feature creep.

I spent 10 years working at GE before I left for SF and the startup world. I was a software engineer at a time when GE was shipping software engineering jobs to India to cut costs. The GE vision for software engineering was that of an assembly line, staffed by large quantities of low wage employees.

GE outsourced the majority of its technical jobs to offshore firms. I remember hearing a statistic that for every 1 GE employee in the technology department there were 4 offshore consultants. The role of GE employees in the technology department shifted from a technical skill-set to a managerial skill-set. Many of my co-workers had degrees in finance and marketing, and had never written a line of code in their life. The lack of technical expertise within the organization created what I would call a culture of fear, where people feared the software they managed because they didn't understand it.

The official term for offshore software engineers was GDC. I have no clue what the acronym stood for, but over time it certainly become a derogatory term. I remember being mocked by my co-workers for writing code and being nicknamed a GDC (as in, why would you do the work we pay people pennies to do). It was almost like a caste system within the company, where these GDC employees were low paid and looked down upon by many.

The offshore model certainly was ineffective and the result of employee discontent, however, the practice was continued and mandated at the executive level. Then the economy crashed. GE decided it was finally time to bring jobs back to the US and hire software engineers. Why? Because they were able to take hundreds of millions in federal tax subsidies from US tax payers. (As an aside, someone mentioned GE moving its HQ to Boston to be closer to engineering talent. Taxes are still the main driver here)

GE soon began hiring US software engineers at a number of designated centers where they were segregated from the rest of the company. The interesting thing is that culturally these employees were largely treated like their GDC predecessors. The perception of software engineers being low-wage assembly line employees was, in my opinion, just too engrained into the company culture.

So when GE describes this transformation to a software company, I believe the most important aspect of this transformation will be changing the company culture and employee attitudes toward software engineers. They will need to undo a decade long effort to turn engineering into an assembly line.

The use case would be implementing the redis protocol for client server communication in your own software. There is a specification for using the redis protocol [1]. The fact that redis is widely used and there are a number of client libraries in many languages may make it an attractive option compared to creating your own protocol from scratch.

I believe disque, the distributed message broker [2] uses the redis protocol for client server communication.

[1] http://redis.io/topics/protocol [2] https://github.com/antirez/disque

I think a more appropriate title would be "Google disables artist's Blog". The author describes the blog and email accounts as disabled and has no direct evidence that anything has been permanently deleted

> I’ve asked about whether the work on Cooper’s blog has been deleted permanently or is simply on a server somewhere, and I’ll update this post if I hear back.

LGTM doesn't currently work with GitHub reactions mostly because the API [1] wasn't available back in November when the project was created. I do personally like comments because they are a bit more visible than reactions, which require you to hover over to see more details.

Now that the reactions API is available it is certainly possible to enable this sort of functionality. I openly encourage people to fork the project and hack into something that works for their team.

[1] https://developer.github.com/changes/2016-05-12-reactions-ap...

I'm a bit late to the party here. I'm the author of the project and happy to answer any questions.

it would definitely be trivial to add the ability to rescind an approval with a -1, for example. Unfortunately I'm a bit bogged down with my other OSS projects at this time, but I would be happy to accept a PR. In fact, this is the function you would want to update https://github.com/lgtmco/lgtm/blob/master/web/hook.go#L100

There are two pull requests we are working to merge that might be of interest. First is the ability to auto-merge once all approvals are received. Second is the ability to auto-tag a release once all approvals are received.

Regarding CI, this generally works in conjunction with a CI server. You can specify, via github protected branches configuration, that both LGTM and your CI checks must pass before merging.

I'm not sure if GitHub Enterprise supports protected branches, since the feature is still considered experimental but it should definitely be possible. I'll be posting a Docker image to the index in the coming weeks allowing you to run your own instance, hopefully that will include GHE conntors

Yes, if you choose the slightly more complex toml format for your MAINTAINERS file you can define approvers, approver subgroups and tweak a bunch of different variables.

Check out https://lgtm.co/docs/approvers/

I agree. I was responding to the parent comment suggesting Sourcegraph should adopt a similar business model to GitLab and I was pointing out that perhaps GitLab's business model has not been proven successful yet

> I did not look at the source code, because of the potential IP issues. What would happen if you looked at the source code and then later worked on another open source project and implemented a bit of code that looks similar?

Could this also be an issue with the GPL? What happens if I look at GPL source code and then author similar code under a non-GPL license? I wonder if a precedent has been set that could be applied to this Fair Source license.

Gitlab graduated from Ycombinator and raised a 4MM series A round. While these are both tremendous accomplishments and important milestones for any startup, it may be a bit premature to declare their business model a success.

This is a really great intro. I like how it expands on the basic flux diagram that I see everywhere.

One thing missing from many flux tutorials and sample applications that I would love to see included is error handling. How do you manage errors in your flux applications? Do you keep them in the store? If using something like react-router, how do you ensure you flush errors from the store as your routes change and they are no longer applicable to the data in view?

Right now it connects directly to the database although I think ultimately it should use some sort of API.

You provide the path to the database, as well as the repositories to monitor, as command line arguments:

drone-wall --repos="github.com/drone/drone,github.com/drone/drone-wall" --datasource="/var/lib/drone/drone.sqlite"

that's a great suggestion. a robotic bee could be awesome

yes, this feature will land in the next few weeks. I'm hoping you'll be able to build the Docker image AND push to the index.